By way of background, a major part of managing a telecommunication network involves observing events or conditions in the network and reacting thereto by taking appropriate actions according to predetermined policies. The events or conditions being observed may range from relatively benign occurrences, such as a video-conferencing call set-up request or a service class provisioning request made by a network administrator, to potentially serious communication problems, such as a network element device being overloaded or a daemon process dying on a given network element host.
Actions taken in response to network events or conditions can be manually performed by an operator, or they may be automated by a network software system. A disadvantage of manual control is that response times may not be fast enough. A disadvantage of software control is that the control policies which cause required actions to be taken according to network conditions are quite often buried in the processing logic (“hardwired”), and are not readily adaptable to application-specific needs.
By way of example, consider the provisioning of a network switching element implementing a managed modem access gateway. Assume there are a two customers “A” and “B,” each of whom gets access to a maximum of 600 modem lines from a set of 1000 modem lines. Assume that “A” has a “Gold” class of service and “B” has a “Silver” class of service, and that it costs the network service provider twice as much to deny a connection request from “A” than from “B.” During peak hours, the line allocation would normally be kept at 600:400 between “A” and B, such that “A” receives its full allocation and “B” suffers a penalty. During off-peak hours, “A's” usage may average around 400, in which case it is not advantageous to keep 200 vacant lines and still deny requests from “B” when they go above 400. Ideally, the service provider would like to implement the following strategy: if sufficient lines are open, and it is off-peak time, then allow “B's” usage to rise to a point where there is just a very small buffer (say 25 open lines) for “A.” At this point, if “A's” calls increase, the system begins declining new requests from “B” until there is again a safe margin reserved for “A.”
Various observations can be made from the above example. A human operator's response to toggle various service classes “on” and “off” may be too slow in practice, and would not scale to scenarios that are anything but trivial. A network software system could respond much more quickly, but the notion of what constitutes “Gold” or “Silver” class would typically come hardwired with the switching element.
A better approach would be to allow the service provider to create its business model and allocate capacity based on experience and growing demands. Although conventional network software systems may offer some degree of configurability, the service provider is typically required to write its own program, in this case one that communicates with the modem pool and sets modem allocation parameters automatically. Such a programming effort may be costly, and the resulting policy may not be easily changeable.
Accordingly, there is a need for a new network management tool that overcomes the foregoing deficiencies of the prior art. Applicants submit that what is required is a network management system that provides automated network control in response to network conditions, and wherein the actions performed by the system can be specified by network service providers at system run-time in an easy-to-implement customizable fashion such that costly reprogramming (or redesign) is avoided.